…cal PR-shaped refs

Two genuine gaps from codex-connector review:

- reserveEntryForNumberedCommit's "skip reservation when an entry lists
  multiple PR numbers" carve-out was itself the bug: it left such an
  entry fully unreserved, so an unrelated un-numbered commit's slug
  match could still reuse it. Each numbered commit referencing that
  entry now reserves it independently (a Set, so idempotent) - no
  carve-out needed, since numbered commits never go through slug
  matching regardless.

- classifyGovernedCommit treated any commit ending in "(#NNN)" as an
  already-merged PR number, even on a feature branch where that token
  may only be an in-flight issue reference GitHub hasn't yet replaced
  with the real squash-merge PR number (this repo's own history shows
  the eventual form "... (#553) (#621)"). Added getBranchLocalCommitCount
  (git merge-base against origin/main, falling back to a local main) so
  commits unique to the current branch are exempted from the exact-PR-
  match requirement entirely, while commits already reachable from main
  stay fully enforced.

Also condensed several QNBS-v3 comments (including one from the prior
commit) down to the required single physical line.

…674)

* fix(docs): upgrade CHANGELOG completeness check, backfill Unreleased

audit F-2: scanUnreleasedTruth's own gate fired only when [Unreleased]
was entirely empty, so a single unrelated doc-sync bullet satisfied
"meaningful content" forever — 13 real feat/fix commits since v1.28.4
went completely undocumented, and the gate never noticed.

- scanUnreleasedTruth now requires every post-tag feat|fix|perf commit
  to be individually referenced in [Unreleased], either by its
  trailing PR number (the mid-subject issue ref some commits also
  carry, e.g. "(#553) (#621)", is correctly ignored in favor of the
  true trailing PR number) or by a bounded subject-slug match (>=60%
  of its most identifying words) for the few commits merged without
  one. Missing commits are named in the failure output.
- Backfilled CHANGELOG.md's [Unreleased] with all 13 currently-
  undocumented commits since v1.28.4 (project schema-version
  classification Slices A/B, the canonical document-projection
  foundation, the legacy-to-v1 admission primitive, filesystem-
  admission convergence, i18n startup-copy fixes, PR-size governance
  hardening, the attribution guard, and this session's own PR-1
  security-doc fix).
- Pulled TODO.md's Current Sprint forward: the 5 landed ledger-row-9
  PRs are now named, still correctly marked not-complete (no target
  release invented — none exists yet).
- 6 new regression tests for the completeness logic; README
  test-count resynced.

* fix(docs): address review findings on the completeness-check upgrade

- PR-number matching used a bare String.includes, so "#65" could
  incorrectly satisfy "#656" and vice versa. Now requires a non-digit
  boundary on both sides.
- Subject-slug matching now runs per Markdown entry (bullet, including
  wrapped continuation lines) instead of against the whole [Unreleased]
  section — words scattered across unrelated bullets could otherwise
  collectively satisfy a commit none of them documents, and one
  generic bullet could simultaneously "document" multiple different
  undocumented commits.
- P1: full per-commit completeness is now enforced only outside
  pull_request CI context. A pull_request run's git-log range
  enumerates every commit unique to that branch, not the one commit
  that will actually exist after squash-merge — a routine review-fix
  follow-up commit can't reference itself in [Unreleased] in advance.
  The section-non-empty check still applies in pull_request context;
  full completeness is enforced locally and on push to main right
  after merge.
- 8 new regression tests; GITHUB_EVENT_NAME declared in turbo.json;
  README test-count resynced.

* fix(ci): stop scanUnreleasedTruth from reading GITHUB_EVENT_NAME as its own default

The isPullRequestContext parameter defaulted to reading
process.env.GITHUB_EVENT_NAME directly. That env var is set by GitHub
Actions for the WHOLE workflow run, not just this gate's own CLI
step -- so when the full Vitest suite ran inside this PR's own
pull_request-triggered Quality Gate job, every test that didn't
explicitly pass isPullRequestContext silently got the lenient
(GITHUB_EVENT_NAME=pull_request) default instead of the intended
deterministic one, failing 7 tests that expected the strict path.

The pure function's default is now a hardcoded false; only main()'s
real CLI invocation reads the actual environment. Verified locally by
simulating the exact failure with GITHUB_EVENT_NAME=pull_request
pnpm exec vitest run -- reproduced the same 7 failures before this
fix, all pass after it.

* fix(docs): address 2nd review wave on the completeness-check upgrade

- P1: the pull_request-context exemption previously skipped strict
  enforcement for EVERY governed commit. Now only an un-numbered
  commit is exempted -- an already-numbered commit sitting in the
  same range from a separate, already-merged PR stays fully enforced
  even during a pull_request run.
- Renamed isPullRequestContext to isFeatureBranchContext and added
  isOnFeatureBranch(): the mandatory local `pnpm run ci:prepush` hook
  invokes this checker with no GitHub Actions event context at all, so
  GITHUB_EVENT_NAME alone left every local review-fix commit strictly
  enforced and unsatisfiable in advance. Checking the actual git
  branch (not just the CI event) means the same exemption now applies
  locally too, on the same reasoning: HEAD not being `main` is what
  actually distinguishes "not yet permanent history" in both contexts.
- A matched changelog entry is now claimed and excluded from later
  commits in the same pass, so one generic bullet can't simultaneously
  "document" multiple different undocumented commits -- verified with
  a case specific enough that both commits would clear the 60%
  threshold alone.
- A commit ending in a trailing PR number now requires that exact
  number; it no longer falls back to a slug match that could hit a
  different, older, unrelated bullet.
- ci.yml's Quality Gate checkout gains fetch-depth: 0 alongside its
  existing fetch-tags: true -- the latter makes a tag ref resolvable
  but doesn't deepen the commit graph, so `git log v<tag>..HEAD` could
  fail or truncate on a shallow checkout, which getPostReleaseCommitSubjects()
  would silently treat as "no history" and skip the whole completeness
  check without ever reporting a failure. Unverifiable from existing
  CI history until this PR's own post-merge push (no push-to-main run
  had exercised the new completeness logic yet) -- applied as a
  correctness fix regardless of prior symptoms.
- My own earlier three CHANGELOG bullets for this feature had drifted
  into exactly the "one bullet documents multiple commits" shape the
  exclusive-claiming fix above now rejects -- restructured into
  separate, distinct bullets.
- 9 new regression tests (exclusive claiming, exact-PR-number
  requirement, un-numbered-vs-numbered PR-context enforcement,
  isOnFeatureBranch against real git repos); README test-count resynced.

* fix(docs): replace greedy slug-entry claiming with maximum bipartite matching

Greedily claiming the first matching entry per commit was order-
dependent: a fully documented changelog could be wrongly rejected
depending only on which commit happened to be checked first. Example:
entries "Alpha beta gamma delta" / "Alpha beta epsilon zeta" against
subjects "alpha beta gamma delta epsilon zeta" then "alpha beta gamma
delta" -- the broader subject greedily claims the only entry the
narrower one can use, even though swapping which entry each takes
documents both.

Replaced with Kuhn's algorithm (augmenting-path maximum bipartite
matching between un-numbered commits and changelog entries), which
finds the best possible assignment regardless of input order. A
numbered commit is unaffected -- it never participated in slug
matching in the first place, per the prior commit's exact-PR-match fix.

2 new regression tests proving the exact adversarial case in both
commit orders; README test-count resynced.

* fix(docs): flatten completeness-check nesting, fix detached-HEAD and self-reference gaps

- Extract classifyGovernedCommit() so findUndocumentedGovernedCommits is a flat
  loop with no nested conditionals (CodeScene Bumpy Road Ahead).
- isOnFeatureBranch() now treats detached HEAD (the literal string actions/checkout
  leaves for every event, push included) as non-feature-branch, so push-to-main
  runs never get silently exempted from full completeness enforcement.
- Add this PR's own eventual squash-merge PR number to the CHANGELOG bullet it
  documents, since the exact-PR-match-required rule would otherwise fail this
  PR's own post-merge CI run.

* test(docs): cover detached-HEAD case for isOnFeatureBranch

Adds the regression test for the detached-HEAD fix in 0c9291c that a
prior reply to the review thread had already described as included -
it was written but not actually committed in that push. Resyncs
README.md's test-count metric for the added test.

* fix(docs): reserve a numbered commit's changelog entry from slug-match reuse

A numbered commit's exact PR-number match never touched entryOwner, so an
unrelated un-numbered commit's slug match could reuse the same bullet and
go undetected as undocumented. Reserve the entry a numbered commit's PR
reference resolves to before slug matching runs, unless that entry
explicitly bundles multiple PR numbers (deliberately shared documentation).

* fix(docs): reserve multi-PR entries fully, exempt in-flight branch-local PR-shaped refs

Two genuine gaps from codex-connector review:

- reserveEntryForNumberedCommit's "skip reservation when an entry lists
  multiple PR numbers" carve-out was itself the bug: it left such an
  entry fully unreserved, so an unrelated un-numbered commit's slug
  match could still reuse it. Each numbered commit referencing that
  entry now reserves it independently (a Set, so idempotent) - no
  carve-out needed, since numbered commits never go through slug
  matching regardless.

- classifyGovernedCommit treated any commit ending in "(#NNN)" as an
  already-merged PR number, even on a feature branch where that token
  may only be an in-flight issue reference GitHub hasn't yet replaced
  with the real squash-merge PR number (this repo's own history shows
  the eventual form "... (#553) (#621)"). Added getBranchLocalCommitCount
  (git merge-base against origin/main, falling back to a local main) so
  commits unique to the current branch are exempted from the exact-PR-
  match requirement entirely, while commits already reachable from main
  stay fully enforced.

Also condensed several QNBS-v3 comments (including one from the prior
commit) down to the required single physical line.

* refactor(docs): flatten main() into a sequence of scanRequiredFiles calls

CodeFactor flagged main() as a Complex Method (five near-identical
read-file/handle-missing/scan loops). Extracted scanRequiredFiles() so
each loop becomes one call; behavior is unchanged (verified via
node scripts/check-doc-metrics.mjs and the full test suite).

* fix(docs): classify branch-local commits by ancestry, guard negation polarity, restrict PR matches to entries

- getBranchLocalSubjectIndices replaces the positional branchLocalCount
  heuristic with a per-commit git merge-base --is-ancestor check, so an
  interleaved main commit (from a branch that merged main back in) is
  never misclassified as branch-local.
- candidateEntryIndices now disqualifies a changelog entry whose negation
  polarity (not/never/no longer/...) differs from the commit description's,
  so a negated commit can no longer slug-match its semantic opposite.
- classifyGovernedCommit checks parsed [Unreleased] bullet entries instead
  of the raw section text, so a PR number mentioned only in surrounding
  prose no longer counts as documentation.

* fix(docs): reject PR-number-boundary letters, typographic apostrophes, and multi-entry reservation gaps

- isReferencedByPrNumber now rejects any word-character continuation after
  the PR number (not just a digit), so a hex-color-like token such as
  #999abc no longer satisfies an exact reference to PR #999.
- NEGATION_MARKER now matches typographic apostrophes (don't) alongside
  straight ones, so a curly-quote contraction is still recognized as negation.
- reserveEntryForNumberedCommit reserves every changelog entry referencing a
  numbered commit's PR, not just the first match, closing a gap where a
  second entry for the same PR was free for an unrelated slug match.
- getBranchLocalSubjectIndices now only classifies a commit as branch-local
  on git's documented exit code 1 (confirmed non-ancestor); any other
  merge-base failure fails closed to the stricter, non-exempted path.
- Corrected a stale comment that no longer matched the scanRequiredFiles
  calls it was describing after they were consolidated.

* fix(docs): recognize avoidance-verb negation and stop truncating slug words

- NEGATION_MARKER now also matches avoid/prevent (and their inflections),
  so a preserve-first commit worded without a literal not/never still
  gets polarity-guarded against an opposite-meaning changelog entry.
- significantSlugWords no longer truncates to the first six words; a
  truncated word list could let a partial-overlap ratio wrongly clear the
  60% threshold when the full word list would correctly fall below it.

* fix(docs): scope branch-local exemption to actual locality, extend refusal-verb polarity, preserve short discriminator tokens

- classifyGovernedCommit's un-numbered exemption now requires isBranchLocal
  too, not isFeatureBranchContext alone, so a commit already reachable from
  main can no longer get a free pass just because the checkout is on a
  feature branch.
- NEGATION_MARKER now also covers refuse/stop/disable (and inflections).
- hasNegationMarker now scopes its check to an entry's **bold** lead claim
  when present (this file's own changelog convention for the actual
  documented change), so a negation word in trailing rationale/context
  prose no longer disqualifies an otherwise-matching entry — found via a
  real false positive this fix produced against this repo's own CHANGELOG.
- significantSlugWords no longer discards a short alphanumeric token (a
  version, a limit) purely for being <=2 characters when it contains a
  digit.

Residual, intentionally out of scope: a short token that IS retained (e.g.
"v2" vs "v1") can still clear the 60% overlap ratio in a longer sentence
where only that one token differs, the same structural tolerance already
documented for the wave-3 truncation fix. Closing that fully would require
identifier-aware or antonym-pair comparison, which is the general semantic
parsing this file's design explicitly avoids.

* fix(docs): sync TODO ledger-row-9 enumeration with CORE-MIGRATION-LEDGER.md row 9 (4 items, not 3)